Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two more spectests that need tweaking to work on Solaris #713

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

nwc10
Copy link
Contributor

@nwc10 nwc10 commented Dec 30, 2020

No description provided.

The test is for reading line-by-line, so trying to change it to handle
binary files defeats the intent.
…laris.

It turns out that `echo $PWD` isn't *quite* portable. The test assumes that
the shell will set the environment variable PWD to the current directory as
part of its startup. This is needed, because the implementation detail being
tested here is that the command is run with a *different* current directory
from the Raku code - ie there is a `chdir` happening as part of the command
invocation, without affecting the invokee.

Solaris (these days) uses ksh93, and *that* turns out to be wonderfully
special. If the current directory is `/` or `~`, then it *does* set PWD (to
the canonical path). Otherwise it leaves PWD unchanged.

I *guess* that this is because it has to figure out the name => (dev,ino)
mapping for these two paths anyway, and it's cheap to stat("."), so it
updates PWD if it happens to find that it knows the pathname corresponding
to "."'s (dev,ino), but doesn't do any extra work if it doesn't recognise
".". I don't find this documented anywhere.

AIX appears to use an older ksh, and that *is* updating PWD.
(That's all the vendor OSes I currently have access to, to test.)

So run `pwd` instead of relying on $PWD being set. I think that this will
also work even if the shell is a Bourne Shell, as I don't believe that
there's any *requirement* for the shell to set this variable.

So Zoffix Znet was correct to write

    Don't know how sanely portable that is...

in Jan 2018 in #375
@lizmat
Copy link
Contributor

lizmat commented Dec 30, 2020

I assume these can be merged before the Solaris work is actually merged?

@nwc10
Copy link
Contributor Author

nwc10 commented Dec 30, 2020

To my mind the strict answer to "can be merged?" is independent of whether MoarVM copes with Solaris :-)

But

MoarVM does now cope with Solaris (ie changes to get it building, at least with gcc) are in, so merging these two changes reduces the number of failing spectests. (if one builds with MoarVM master)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants